Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[vaPutSurface] do not reuse previous vpp context #944

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

xuguangxin
Copy link
Contributor

We usally use vaPutSurface in a renderer thread. It's different than vpp thread.
Reuse the vpp context will introduce a thread race condition issue.

@XinfengZhang
Copy link
Contributor

seems it could not avoid race condition, why not create temp vpp context and destory it after execution ? if you want to avoid create/destroy frequently , you should not store it in mediaCtx

@xuguangxin
Copy link
Contributor Author

seems it could not avoid race condition, why not create temp vpp context and destory it after execution ? if you want to avoid create/destroy frequently , you should not store it in mediaCtx

you mean we should protect PutSurfaceContext ?

@xuguangxin
Copy link
Contributor Author

@XinfengZhang do you think need to protect entire vaPutSurface call with some lock?

Copy link
Contributor

@Xiaogangli-intel Xiaogangli-intel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@xuguangxin For race condition, we have PutSurfaceRenderMutex/PutSurfaceSwapBufferMutex to protect it. Is that still not enough, did you meet any issue currently?

@xuguangxin
Copy link
Contributor Author

xuguangxin commented Jun 8, 2020

@Xiaogangli-intel , yes, it will reuse the previous vpp context. image following usecase:
decode -> vpp-> renderer. render will use vaPutSurface in another thread. the render thread will race with vpp thread.

We usally use vaPutSurface in a renderer thread. It's different than vpp thread.
Reuse the vpp context will introduce a thread race condition issue.
@xuguangxin
Copy link
Contributor Author

xuguangxin commented Jun 16, 2020

@XinfengZhang @Xiaogang-Li , protectted the vp context creation. please help review it again.

thanks

@xuguangxin
Copy link
Contributor Author

@XinfengZhang @Xiaogang-Li , are we ready to merge this?
thanks

@xuguangxin
Copy link
Contributor Author

@XinfengZhang are we ready to merge this?
thanks

@xuguangxin
Copy link
Contributor Author

@XinfengZhang , any feedback for this?
thanks

@xuguangxin
Copy link
Contributor Author

@XinfengZhang @Xiaogang-Li any more suggestion on this?
thanks

@xuguangxin
Copy link
Contributor Author

@XinfengZhang any more comment for this?
thanks

}
vpCtx = (PDDI_VP_CONTEXT)DdiMedia_GetContextFromContextID(ctx, mediaCtx->PutSurfaceContext, &ctxType);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we move these lines into mutex protection part considering here vphal is used? Thanks.
DdiMediaUtil_LockMutex(&mediaCtx->PutSurfaceRenderMutex);
eStatus = vpHal->Render(&renderParams);
if (MOS_FAILED(eStatus))
{
DdiMediaUtil_UnLockMutex(&mediaCtx->PutSurfaceRenderMutex);
mos_bo_unreference(drawable_bo);
return VA_STATUS_ERROR_OPERATION_FAILED;
}

DdiMediaUtil_UnLockMutex(&mediaCtx->PutSurfaceRenderMutex);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Furong,
Thanks for the review. It may not needed.
Above lock just protect us for context creation. Once it created, it only destroy at uninitialized time.
The DdiMedia_GetContextFromContextID will hold a lock, and later operation like "vpHal->Render(&renderParams);" is protected by lock too.
So the entire process is thread safe.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants